The client-server model of computer process interaction is widely used. According to the client-server model, a client process sends a message including a request to a server process, and the server process responds by providing a service. The server process may also return a message with a response to the client process. Often the client process and server process execute on different computer devices, called hosts, and communicate via a network using one or more protocols for network communications.
The term “server” is conventionally used to refer to the process that provides the service, or the host computer on which the process operates. Similarly, the term “client” is conventionally used to refer to the process that makes the request, or the host computer on which the process operates. As used herein, the terms “client” and “server” refer to the processes, rather than the host computers, unless otherwise clear from the context.
A database server provides database services in response to requests from a database client. For example, the database server writes data received in the request into one or more data containers in a particular database managed by the database server; or, the database server retrieves data from one or more of those containers that satisfy conditions specified in the request; or, it does both. In many circumstances the database client is a mid-tier application, distinct from the database server, which performs other services, such as accounting services, for one or more application users. The application itself may be configured for client-server operations, so that application users operate application clients that make application requests to an application server.
Not all users of a database server are granted access to all data in all the database objects managed by the database server. Consequently, it is common for a database server to implement access controls that control access of database users to the data in the database. Many access control mechanisms are known; for example, a uniform access control mechanism described in Murthy provides access controls for data content that appears to a database user to be organized in a hierarchy of storage containers, or in a relational database of tables with defined columns, or both.
The access controls are often implemented as privileges to perform database operations, with a set of one or more privileges associated with each user of the database for a particular data item or group of data items in the database. For example, basic privileges are defined for performing basic database operations, such as operations to read, insert, delete data of a data item, which may reside in a database object such as a table, or operations to create, modify or delete database objects themselves.
A privilege to perform a basic database operation may be associated with a particular level of the several levels of the database. The levels of a database include, for example, a level of a data item, a level of a database object of several data items, a level of a node of a hierarchy of several database objects, and a level of a parent node of several descendent nodes of database objects. When a privilege is associated with a particular level, the privilege may apply to all items at that level.
In some database management systems, a hierarchy of privileges may be defined, each node in the hierarchy representing the privilege to perform a certain combination of basic operations on one or more levels of the database. To support this hierarchy of privileges, the database servers in some database management systems provide infrastructure to describe privileges, to associate users and data items with privileges, and to efficiently store and retrieve information in a fast memory cache about the privileges to determine quickly whether the database user may perform a requested database operation on a requested data item or database object.
An infrastructure that supports access control to a database based on privileges to perform database operations provides the access control at the granularity of database operations. However, the ability to provide access control at the database-operation level of granularity is not particularly useful when one wants to control access based on operations defined in an application that uses the database. Such operations are referred to herein as “application-specific” operations.
For example, in an application to manage purchase orders for an enterprise, application-specific operations include: creating a new purchase order, approving the purchase order, issuing the purchase order to make a purchase, associating an invoice with a particular purchase order, confirming acceptance of an order delivered, and clearing the purchase order by paying the associated invoice. If certain application users are to be given privileges to perform some of these application-specific operations but not others, then access control must be provided at the application-specific-operation level of granularity. Since this level of granularity of access control is not provided by the database server, the developer of each application that uses application-specific-operation privileges must design and implement access control software that manages different privileges for different users.
There are several disadvantages to developing access control software for each application. One disadvantage is that the cost of developing the application is increased because development resources are consumed to generate the software to implement the access controls. The more sophisticated the access controls, the more costly the development costs. Conversely, the less spent on developing access controls, the less sophisticated are the access controls implemented. Another disadvantage is that access controls developed for the new application are often less efficient than access controls already developed for some systems and servers over many years. For example, some database servers have evolved with access controls that use minimal computational resources, including using efficient caching of data indicating user privileges.
Furthermore, administrators of multiple applications with independently developed access control mechanisms may have to contend with disparate interfaces for expressing the hierarchy of privileges and expressing the associations of application users and data items with those privileges. If the same access control infrastructure were available across multiple applications, the administrator for those multiple applications could more readily enter information about privileges and associated users and data items, with less concentration and fewer errors.
Based on the foregoing description, there is a clear need for making available to database applications the efficient access control mechanisms of database servers. In general, there is a need for making available to any application the sophisticated and efficient access, control mechanisms already implemented in a separate server.
The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not to be considered prior art to the claims in this application merely due to the presence of these approaches in this background section.